Capx AI: a critical SSRF, fully closed before launch
A web application and API penetration test for Capx AI, covering the web application and backend APIs, Web3 wallet-based authentication, Firebase authentication infrastructure, and on-chain transaction logging endpoints.
Seven findings, one critical
What the engagement found
A critical SSRF in the API proxy endpoint, allowing the server to be forced into contacting internal infrastructure and cloud metadata services.
A Firebase authentication misconfiguration permitting unrestricted creation and upgrade of arbitrary accounts, including ones impersonating internal email domains.
Replayable wallet signatures in the Web3 login flow, allowing indefinite session and token regeneration without a freshness check.
Unvalidated client-supplied transaction data, allowing users to fabricate or alter their own on-chain transaction history.
Missing and misconfigured HTTP security headers, including an incomplete Content Security Policy, increasing exposure to XSS and clickjacking.
Server and framework information disclosure aiding attacker reconnaissance.
The critical SSRF, the Firebase account-creation flaw, the transaction log manipulation issue, and the missing security headers were fully remediated. The wallet signature replay issue was also resolved, via a nonce-based challenge system.
If this looks like your environment, it probably behaves like it too
Token issuance and launch platforms.
Fintech companies deploying automated financial protocols.
Platforms where automated business logic directly handles user fund routing, allocation, or conversion.
Questions engagements like this raise
Why is SSRF against cloud metadata services considered critical?
Cloud metadata endpoints can return credentials and configuration for the infrastructure itself. An SSRF that reaches them can escalate from a single vulnerable proxy endpoint to control over the surrounding cloud environment.
What is a wallet signature replay in a Web3 login flow?
If a signed message used to prove wallet ownership has no freshness check, such as a nonce or expiry, the same signature can be reused indefinitely to regenerate sessions without the wallet holder signing anything new.
Why does Firebase misconfiguration matter if the app also uses wallet auth?
Many Web3 apps still use Firebase for account and session infrastructure alongside wallet login. A gap there can let an attacker create or upgrade accounts entirely outside the wallet-based trust model.
Was the fix for wallet signature replay unusual?
It was resolved with a nonce-based challenge system, requiring a fresh, single-use value in every signed message, which is standard practice but one skipped in the original implementation.
Other engagements
Start with a scoped assessment
Tell us what you are securing. We reply with scope and next steps within one business day.
Prefer to see it first? Book a demo ↗
Already a CredShields One customer? Log in ↗